Effort estimation of FLOSS projects: A study of the Linux kernel

This is the post-print version of the Article. The official published version can be accessed from the link below - Copyright @ 2011 SpringerEmpirical research on Free/Libre/Open Source Software (FLOSS) has shown that developers tend to cluster around two main roles: “core” contributors differ from “peripheral” developers in terms of a larger number of responsibilities and a higher productivity pattern. A further, cross-cutting characterization of developers could be achieved by associating developers with “time slots”, and different patterns of activity and effort could be associated to such slots. Such analysis, if replicated, could be used not only to compare different FLOSS communities, and to evaluate their stability and maturity, but also to determine within projects, how the effort is distributed in a given period, and to estimate future needs with respect to key points in the software life-cycle (e.g., major releases). This study analyses the activity patterns within the Linux kernel project, at first focusing on the overall distribution of effort and activity within weeks and days; then, dividing each day into three 8-hour time slots, and focusing on effort and activity around major releases. Such analyses have the objective of evaluating effort, productivity and types of activity globally and around major releases. They enable a comparison of these releases and patterns of effort and activities with traditional software products and processes, and in turn, the identification of company-driven projects (i.e., working mainly during office hours) among FLOSS endeavors. The results of this research show that, overall, the effort within the Linux kernel community is constant (albeit at different levels) throughout the week, signalling the need of updated estimation models, different from those used in traditional 9am–5pm, Monday to Friday commercial companies. It also becomes evident that the activity before a release is vastly different from after a release, and that the changes show an increase in code complexity in specific time slots (notably in the late night hours), which will later require additional maintenance efforts

Code Review Analytics: WebKit as Case Study

Part 1: Open Source Visualization and ReportingInternational audienceDuring the last years, most of the large free / open source software projects have included code review as an usual, or even mandatory practice for changes to their code. In many cases it is implemented as a process in which a developer proposing some change needs to ask for a review by another developer before it can enter the code base. Code reviews, therefore, become a critical process for the project, which could cause delays in contributions being accepted, and risk to become a bottleneck if not enough reviewers are available. In this paper we present a methodology designed to analyze the code review process, to determine its main characteristics and parameters, and to detect potential problems with it. We also present how we have applied this methodology to the WebKit project, learning about the main characteristics of how code review works in their case